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ABSTRACT 


The cornerstone to achieving battlefield dominance, as defined by Joint Vision 2010, 
is establishing and maintaining information superiority. This new paradigm of netwoiic 
centric warfare has shifted computer networking from an administrative support system to a 
tactical necessity. Recognizing this critical requirement for interoperable networking, the 
Department of the Navy promulgated the Information Technology for the Twenty-First 
Century (IT-21) computing standards. This thesis investigates the synergetic interactions 
between application software, the Windows™ NT operating system, and the underlying 
networks. The insight gained is then exploited to develop performance analysis software in 
C-H-. The resulting application provides a valuable asset for examining, troubleshooting, and 
optimizing IT-21 information systems. 



TfflS PAGE INTENTIONALLY LEFT BLA^JK 


VI 



TABLE OF CONTENTS 


L INTRODUCTION_1 

A. THESIS OBJECTIVE.1 

B. THESIS ORGANIZATION.2 

n. BACKGROUND_3 

A. IT-21 NETWORK TOPOLOGY. 3 

B. WINDOWS'™ NT ARCHITECTURE.5 

1. Basic Structure.5 

2. The Registry.6 

3. Communication Sub-Stmcture.7 

4. Network Sockets.8 

C. IT-21 SYSTEM ANALYSIS REQUIREMENTS.8 

in. THE DESIGN_ 11 

A. DEVELOPMENT ENVIRONMENT.11 

B. BASIC STRUCTURE.13 

C. CONFIGURATION INFORMATION.14 

1. Using The Registry Networking Entries.15 

2. Implementation Overview.16 

3. Data Collection and Handling.16 

4. GUI Design.16 

D. NETWORK ACCESS AND TIMING.18 

1. Timing and Timers.19 

2. Socket Support.20 

E. COMMUNICATIONS CONTINUITY AND CONNECTIVITY.20 

1. ICMP and IP.21 

2. Implementation Issues.21 

3. GUI.21 

F. BENCHMARKING.23 

vii 































IV. RESULTS AND PERFORMANCE 


27 


V. CONCLUSION.. 

A. SUMMARY OF WORK. 33 

B. FUTURE WORK. 33 

APPENDIX A. INFORMATION TECHNOLOGY FOR THE TWENTY-FIRST 
CENTURY (IT-21). 35 

APPENDIX B. HUNGARIAN NOTATION. 39 

APPENDIX C. CLASS OVERVIEW.. 

LIST OF REFERENCES. 45 

IMTIAL DISTRIBUTION LIST. 47 











LIST OF FIGURES 


Figure 1: IT-21 In Naval Networking.4 

Figure 2: NT Structure the operating system.6 

Figure 3: The OSI Model and Windows™ NT.7 

Figure 4: General Application Structure.14 

Figure 5: Network Adapter and Driver Registry Entries.15 

Figure 6: Installed Protocols GUI Layout.17 

Figure 7: Installed Adapters GUI Layout.18 

Figure 8: Connectivity and Continuity GUI Layout.22 

Figure 9: Benchmarking GUI Layout.24 


IX 












THIS PAGE INTENTIONALLY LEFT BLANK 



ACRONYMS AND ABBREVIATIONS 


API 

Application Programming Interface 

ATM 

Asynchronous Transfer Mode 

COTS 

Coirimercial Ofif-the-Shelf 

DON 

Department of the Navy 

GUI 

Graphical User Interface 

GUID 

Globally Unique Identifier 

HAL 

Hardware Abstraction Layer 

IP 

Internet Protocol 

IS 

Information Systems 

IT-21 

Technology for the 21st Century 

LAN 

Local Area Network 

LLC 

Logical Link Control 

MAC 

Media Access Control 

MFC 

Microsoft Foundation Classes 

NDIS 

Network Device Interface Specification 

NIC 

Network Interface Card 

NSAP 

Network Service Access Point 

OSI 

Open Systems Interconnection 

PVC 

Permanent Virtual Circuit 

QoS 

Quality of Service 

SNMP 

Simple Network Management Protocol 

SPI 

Systems Progranoming Interface 

SVC 

Switched Virtual Circuit 

TCP 

Transport Control Protocol 

UDP 

User Datagram Protocol 

WSA 

Windows Sockets API 

WSC 

Windows Socket Configuration 


XI 



TfflS PAGE INTENTIONALLY LEFT BLANK 


xii 



ACKNOWLEDGMENT 


I would like to take this opportunity to recognize the outstanding support I received 
with this thesis. The glory and credit belong to the Lord Jesus Christ for giving me the 
opportunity to attend NFS and bringing friendly, helpful people into my life. To both 
professors John McEachen and Murali Tummala, I really appreciate the time and support 
you sacrificed for me fi'om your busy schedules. To all the Fore Systems technical support 
representatives, thank you for the prompt and helpful assisting in implementing the Fore 
ATM service provider interface. And to the administrative support staff, with special 
emphasis to Alice Lee and Sue Netzorg, your outstanding support was instrumental in 
making my tour of duty at Naval Postgraduate School enjoyable and successful. 


Xlll 



TfflS PAGE INTENTIONALLY LEFT BLANK 



I. INTRODUCTION 


On March 30, 1997, the U.S. Navy promulgated a new policy for all Department of 
the Navy (DON) information systems (IS); Information Technology for the 21®* Century 
(rT-21). [1] IT-21 mandates Windows™ NT based hosts on fast Ethernet local area 
networks (LANs) coimected by asynchronous transfer mode (ATM) backbones. 

With the increasing emphasis on network centric warfare and battlefield information 
dominance, the performance and reliabihty of the Navy’s IT-21 systems is critical to the 
ability to effectively engage in operations. This reliance on IS gives the network support 
persormel a direct, critical role in the success of warfare missions. 

In order to effectively support operations, these administrators need to configure, 
monitor, optimize, and test networks quickly and effectively. There are many commercial 
off-the-shelf (COTS) tools available to assist network support personnel, hereafter referred 
to as administrators. However, most of these tools are very expensive and many operate on 
only a small sub-set of the installed network components. This thesis will focus on 
designing a tool to provide a wide range of services to administrators across all the 11-21 
networking standards. 

A. THESIS OBJECTIVE 

This thesis will design, develop, test and analyze the performance of an IT-21 
comphant network analysis software package. The primary objective is to design fully 
functional network analysis software that can be easily upgraded and expanded. Developing 
this software serves three primary purposes: 

1. Provides a valuable tool to the fleet. 

2. Provides a useful utility to the advanced networking lab at the Naval 
Postgraduate School (NPS) in support of other networking research. 

3. Documents how protocols and networking services are implemented in 
Windows™ NT with emphasis on how to properly use them in network 
application development and performance analysis. 
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B. THESIS ORGANIZATION 

This thesis is organized as follows: Chapter II covers the foundational infonnation 
underlying both IT-21 application and analysis principles. It begins by discussing IT-21 
network topology as implemented in the fleet and then briefly covers the Windows™ NT 
implementation details significant to network performance. It concludes by deriving file 
required functionality for a comprehensive IT-21 configuration and analysis utility. 

Chapter IE explicitly details how each functional component is designed. It will 
emphasize both the implementation method and the internal details of Windows™ NT that 
apply. 

Chapter IV will provide analysis of performance. Chapter V will summarize work 
accomplished and provide ideas for follow-on work. 

Appendix A is a copy of the IT-21 Naval message. Appendix B will detail the 
Microsoft™ recommended Hungarian naming convention used in this project, and is 
extremely useful when reading the Microsoft™ examples and sample code. Appendix C 
contains a description of each class developed for this project. 
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II. BACKGROUND 


The client computers and underlying networks that comprise the DON IS assets 
provide an invaluable cohesive communications service. Optimizing the end-to-end 
performance of this service, not that of each single networking component is a predominate 
DON objective. Therefore, optimization techniques must balance a wide set of 
requirements. In addition to high-speed coimectivity, the critical nature of military 
operations requires a very high degree of reliability. Further complicating system 
optimization, the mobile, maritime network participants introduce a uniquely dynamic 
communication topology. Finally, when optimizing current performance, the administrator 
needs to retain the flexibility to innovate, conduct research, and field upgrades in order to 
maintain a maximum state of readiness. 

While the primary goal of both network engineers and administrators is to optimize 
communications reliability and speed to the user, the process varies for each network 
topology. Each physical implementation and protocol provides its own unique suite of 
requirements. In addition, each client operating system must also be included in the 
optimization process because its implementation of transport protocols directly relates to 
users’ observed network performance. In short, network engineers and administrators would 
benefit greatly fijom a single utihty designed to analyze each networic component and 
provide a complete, coherent representation of the network’s current condition. Therefore, 
the IT-21 network topology is a fundamental basis to the design of a compressive network 
analysis utility to support the Navy’s networking needs. 

A. IT-21 NETWORK TOPOLOGY 

To increase interpretability and reduce support requirements, the IT-21 specification 
sets standards for all hardware, software, and LAN technology employed in DON systems. 
The three primary requirements that effect data communications performance are: 
Windows™ NT 4.0, Fast Ethernet LANs, and ATM backbones. This straightforward 
specification works well at established, shore stations; however, the naval networks required 
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in support of real-world operations are much more complicated because of their inherent 
dependence on dynamic composition, participant mobility, secure encryption, and wireless 
communication links. A simplified configuration for a typical naval network is shown in 
Figure 1. In addition to the aforementioned challenges, naval communications networks 
integrate voice traffic, support legacy networks, and must integrate with non-compliant 
networks like the naval tactical data system (NTDS). 
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Figure 1: IT-21 In Naval Networking 


In order to ensure reliable networking services, mobile units need the ability to 
monitor and measure individual performance of each organic networking component (client 
computers, Ethernet LAN segments, ATM pipes) and their combined performance. In 
addition, the ability to obtain performance information about the inorganic networking links 
to remote sites increases the ability to pinpoint communications bottlenecks and 
breakdowns, increasing reliability by facilitating coordinating between network 
administrators. 
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The IT-21 architecture requires an edge device between the Ethernet and ATM 
network segments. A Windows™ NT server with multiple network interface cards (NICs) 
can serve as a cost effective edge device, but may introduce troubleshooting difficulties. 

B. WINDOWS™ NT ARCHITECTURE 

A fundamental basis to IT-21 system performance is the networking implementation 
inherent in the required Windows™ NT operating system. Windows™ NT is designed as a 
secure, modular computing system, which profoundly impacts its structure, implementation, 
use, and interpretation. Its design also has serious implications for the networking support 
implementation. Other significant design aspects include service providers, sockets, timers, 
and computing precision. 

1. Basic Structure 

Windows™ NT is foundationally designed according to the concept of a reference 
monitor. There are three criteria a reference monitor must satisfy: 

• Absolute control—the reference monitor must completely control all access 
to hardware and software components. 

• Isolation—the kernel must be a separate, self-contained entity protected from 
alteration or outside influences. 

• Verifiability—the kernel must demonstrate it enforces the required security 
policies. 

The NT kernel executes in privileged mode and controls all access to networking and timing 
assets. Software applications execute in protected mode and request access to assets from 
the kernel using standardized application programming interface (API) calls. 

In keeping with the principle of isolation, the kernel is also separated from the 
installed hardware by the hardware abstraction layer (HAL). Device drivers are the software 
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Figure 2: NT Structure the operating system 


components that directly control hardware^ and must provide the HAL required interface to 
This standard interface allows the NT kernel cross-platform portability. An overview the NT 
architecture is shown in Figure 2. 


2. The Registry 

One important byproduct of the HAL and of the multi-level security scheme is 
Windows™ NT relies on a database of configuration information to interface with its 
hardware. During boot-up NT scans the computer’s buses and hardware ports for installed 


' This does not hold for printing assets. MicrosoftTM refers to printing hardware as print devices. The drivers for print 
devices are called printers, (e.g. The HP 4000 printer is the software driver to control an HP 4000 print device.) 
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hardware and checks to insure that there is an entry for each in the registry. DupUcate, 
obsolete, and superfluous registry entries not detected. 

The registry is structured much like the computer’s file system, but instead of 
directories and files it has keys and values. Keys can contain other keys and values. Values 
can consist of character strings, DWORDs (32 bits), or binary data. 

3. Communication Sub-Structure 

The open systems intercoimect (OSI) communications model is often used to 
conceptualize how communications should function. Figure 3 shows how the OSI model 
relates to the NT networking implementation. [2] In addition to the OSI model. Figure 3 also 
shows the relationship to the user and kernel operating modes. 
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Figure 3: The OSI Model and Windows'™ NT 


At the ^phcation level, user applications execute in protected mode. These 
applications interface with the presentation level through API calls to the NT kernel. The 
kernel supports the session layer through calls to dynamic linked hbraries (DLLs). The 
transport and network layers and their interfaces correspond to the service providers in NT. 
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While protocols are platform independent specifications, their implementation is 
unique and affects their compatibility. Windows™ NT implements protocols and supports 
name resolution with service providers. It is important to understand the distinctions of the 
terminology: MSAFD Tcpip is the Microsoft™ supplied service provider that implements 
the fimctionality for the TCP, UDP, and IP protocols. Therefore, protocol names are used 
when referring to properties native to the protocol specification; service provider names are 
used when referring to implementation issues. 

The data link layer is composed of the logical link control (LLC) and media access 
control (MAC) sub-layers. The LLC fimctions above the HAL and is implemented with the 
network device interface specification (NDIS) 3 . 0 , a joint Microsoft™ and 3Com™ 

specification. The MAC is implemented with device drivers; therefore, it operates below the 
HAL. 

4. Network Sockets 

The most important commumcations programming mechanisms provided by 
Windows™ NT are Windows Sockets (Winsock), which are based on Berkeley software 
distribution (BSD) sockets. [2] A socket is a communications endpoint and is either 
blocking or non-blocking. Blocking sockets force the calling application to wait while they 
execute; non-blocking sockets return control to the calling program immediately. 

Winsock is implemented in both 16- and 32-bit modes. In its first incarnation, 
Winsock 1.0 (winsock.dll), only the TCP/IP suite of protocols was supported. Winsock 2.0 
(ws2_32.dll) includes support for other protocols (ATM) and implements quality of service 
(QoS) support. The Winsock fimctions execute in privileged mode and provide only the 
access allowed to the calling program’s security level. 

C. IT-21 SYSTEM ANALYSIS REQUIREMENTS 

The IT -21 IS suite is a complete system comprised of many fimctional components, 

including client computers, local networks, and commumcations links. In this system, users 

run client software, which interfaces with the NT kernel to access network assets and 

communicate. The entire system must work in harmony to maximize rapid, reliable access 

8 



to infoimation. While application responsiveness and proper GUI design can significantly 
enhance the user’s perceived performance, the network engineer is typically more concerned 
with performance, precision, and accuracy. Because the performance afforded to the user 
must be optimized, the ability to test all networking components from a s in gle application 
and correlate those results into a coherent picture of system performance would be an 
invaluable asset. To convey a complete understanding of system performance, a network 
analysis tool should provide detailed configuration descriptions, useful testing and 
verification utilities, and measure performance benchmarks. 

Because accessing networking assets reUes on the configuration information stored 
in the registry, the registry networking entries are crucial in troubleshooting, optimizing, and 
developing distributed applications. While Windows™ NT includes two utilities, regedit 
and regedtSl, to display and edit the registry, both are too unwieldy and unintuitive to 
provide a practical method for viewing network configurations. Therefore, networking 
analysis software should begin by consolidating and displaying the networking entries in a 
legible format. Configuration information for all networking assets should be included: 
network adapters, networking drivers, and installed protocols. The bindings betweai 
adapters and protocols can be viewed and edited from Control Panel-> Network, tnaking 
their inclusion iinnecessary. 

Networking analysis software should also be able to verify network end-to-end 
connectivity, trace network routes, and isolate trouble spots. Windows™ NT includes the 
two ubiquitous command line utilities, ping and tracert, which support these functions for 
TCP/IP networks. This software will include enhanced versions of these utilities. 

In order to analyze and optimize 11-21 networking services, Ethernet, ATM, and 
composite performances must be measured. Providing benchmark measurements of the end- 
to-end connections at the transport layer will provide a good indication of composite 
performance. Complete networking analysis also requires the ability to measure the 
performance of each network segment at the network layer. This thesis will implement this 
abihty for ATM adaptation layer (AAL) 5, best effort traffic because it is the most common 
class of traffic on the network backbones. 
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Network analysis software should be modular to support maintainability, upgrading 
and expansion; incorporate multi-threading to improve usabihty and allow benc hmarking in 
execution contexts; and follow the Microsoft™ recommended GUI guidelines. The 
measurement uncertainties due to preemptive multi-tasking must be accounted for to 
provide the most accurate results possible. 


ni. THE DESIGN 


While this networking analysis software is a valuable tool for both network 
administration and research, examining the design process and code structure provides 
valuable insights into networking performance theory and implementation issues. Software 
applications are built on the foundations provided by the software development tools used to 
create them. Implementing networking support efficiently is essential to all network 
^plications and is especially critical in performance analysis. Performance measurements 
are also dependant on the accuracy and precision of the timers used. Developing robust 
utihties to determine network status and configurations provides a good foimdation for the 
more advanced and difiBcult benchmarking routines. 

A. DEVELOPMENT ENVIRONMENT 

There are many programming languages and development environments available to 
build software ^plications. Despite the recent hype over Java™, the increased flexibility, 
robustness, and innate power of C++ make it the language of choice for developing 
advanced networking j^plications. This thesis uses the Microsoft™ Visual €++ suite for 
code development. 

Windows™ NT applications can be developed to run in protected mode using a 
software development kit (SDK) or in privileged mode using a device driver developmait 
(DDK) kit. Privileged execution provides direct access to the installed network hardware 
components, allowing advanced functionality like ATM cell capture and Ethernet 
promiscuous mode. Unfortunately, this unrestricted access incurs several high costs, 
including lack of code portabihty, increased programming complexity, and debugging 
difficulties. Because this mode of execution operates below the Winsock DLL, socket 
siq)port is not available for these advanced functions. 

Protected mode execution relies on the NT kernel for access to network services. 
This restricts functionality to those services supplied by the NT operating system or the 
installed hardware drivers. While protected mode progr amming precludes providing cell 
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capture and other abilities requiring direct, low-level access, it is capable of providing 
precise and accurate performance estimates. Because the NT operating system provides 
sufficient functionality to measure networking performance and implement many network 
analysis utilities, programming in the more difficult privileged mode is not required. In 
addition, protected mode programming produces portable, easily maintained code. 

When using Visual C-H-, apphcation code for Windows™ NT interfaces with the 
operating system through either the raw Windows™ application programming interface 
(API) or the Microsoft™ foundation classes (MFC). The MFC libraries encapsulate much of 
the Windows™ API, providing an easier programming interface at the expense of additional 
overhead. The MFC libraries are designed to support embedding raw Windows™ API 
function calls; therefore, there is no good reason not to use the MFC API. 

Microsoft™ strongly recommends using the document/view architecture and has 
implemented MFC’s support for many of an application’s basic features in the 
document/view functions. [6] The document/view architecture exploits the object oriented 
programming (OOP) features of C++ and conceptually separates an application into 
document objects and view objects. Document objects, derived from CDocument, read, 
write, and control access to data. View objects, derived from CView, display data and allow 
the user to select or edit data. While CDocument functionality is not necessary, the robust 
display tools in the MFC view classes make the document/view architecture an ideal 
development framework. 

MFC documenWiew based applications use either single document interface (SDI) 
or multiple document interface (MDI) windows. The capability to handle more than one 
document at a time is not required for this design. However, this application uses MDI 
because of its ability to display multiple child windows simultaneously. 

The MFC libraries, Windows API, and sample source code incorporate Hungarian 
notation, a programming convention named after the nationahty of its creator: Microsoft™ 
programmer Charles Simonyi. In its simplest form, Himgarian notation advocates appending 
lowercase prefixes to variable names to indicate their type. The fundamental purpose of 
Hungarian notation was to increase the legibility of C code. Unfortunately, different dialects 
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have formed over time (at least four partially incompatible dialects just within Microsoft™). 
[6] This thesis will use the common dialect outlined in Appendix B. 

B. BASIC STRUCTURE 

Network analysis software must collect and display information about the available 
networking assets and must employ those assets to provide networking services. Both of 
these fimctions require extracting information fi-om the local computer. Therefore, the 
design begins with a CDocument derived object to collect all the available networking 
related information from the local computer during initialization. This will allow the 
application to be easily upgraded to support storing configuration information to disk for 
reference purposes and accessing remote computer’s networking configurations. 

Networking support is implemented through an object encapsulating socket support. 
This object also includes timing support and returns execution times for fimctions. By 
including the timing support with the network access object, the code design becomes more 
modular. 

Each major application activity is implemented through a CView derived object. 
These objects encapsulate both the GUI and the required computational fimctionality. The 
code stmcture provides for easy expansion. Figure 4 provides a graphical representation of 
the application stracture. 
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Figure 4: General Application Structure 


C. CONFIGURATION INFORMATION 

As mentioned earlier, Windows™ NT stores its networking configuration 
mformation on adapters, drivers, protocols, and bindings in the registiy. Because the 
accuracy of this information directly affects networking performance, the abihty to access it 
is significant to administrators, network engineers, and network programmers. Improper, 
duphcate, or obsolete networking registry entries can degrade observed networking 
performance, invalidating analysis software results. 
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1. Using The Registry Networking Entries 

Accessing the registry requires opening one of the keys, reading or writing values 
under that key, then closing the key. A limited number of keys can be open at any one time; 
therefore, keys should be released as quickly as possible. The Windows™ API provides a 
suite of functions to manipulate registry entries; MFC encapsulates registry manipulation in 
the CRegKey class. Figure 5 illustrates how the network adapter and driver entries are stored 
in the registry. 

3 m HKEY_LOCAL_MACHINE 
3 SYSTEM 

B «a CurrentControlSet 
3 tt! Services 

B * Adapter_Nametf 
1 Type 
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: H • 

m M Enum 
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Figure 5: Network Adapter and Driver Registry Entries 

The entries for network adiqjters and their drivers are not grouped in a single 
location, but are dispersed iu the registry. In addition, the configuration for both adapters 
and drivers are listed tmder the ... \Services\Adapter_Name#\ key. Therefore, at least two keys are 
required for each NIC, typically ...\Services\Adapter_Name\ and ...\Services\Adapter_Namel\. The 
Type value identifies wheflier the entry is for the adapter (0x04) or its driver (0x01). The 
...\NetworkCards\#\ keys are linked to the corresponding ...\Services\Adapter_Name#\ entries by 
their ... \#\ProductName and... \§\ServiceName values (not exphcitly shown in Figure 5). 
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While protocol configuration parameters are also spread across several distributed 
registry keys, the Win32 API provides two functions to retrieve this information: 
WSAEnumProtocols(...) and the more robust WSCEnumProtocols(...). 

2. Implementation Overview 

During initialization, this network analysis package will instantiate a CDocument 
derived object to obtain the networking configuration of the local machine. The installed 
adapter and protocol parameters will then be formatted and displayed in a simple, 
straightforward manner using CView derived objects. The GUI should epitomize 
completeness and clarity. 

3. Data Collection and Handling 

The object used to collect and manage the network configuration data was derived 
fi:om CDocumsTit to provide CVisw coordination through mheritance. It uses three private 
arrays to store the parameters: protocol parameters, network adapters, and network drivers. 
The inherited persistence (disk storage) support is not used, but could be exploited in future 
versions to save, compare, and verify the networking registry entries. 

4. GUI Design 

It seems reasonable to display the adapter and protocol configurations in separate 
windows. In both cases, the analysis software must list the installed components, clearly 
demonstrate their relationships with each other, and detail the configuration and infoimation 
associated with each. After much trial-and-error, I found the optimum format for organizing 
all this information in a single interface was to split a -window into halves: The left half 
composed of a tree control, allowing the user to select fi-om a list of the installed 
components; the right half displaying the configuration information for the selected 
component. 

MFC supports split windows with CSplitterWindow. This class is derived directly 
from CWnd-, therefore, it lacks CView functionality. During initialization, CView derived 
objects are inserted as static panes in the splitter window (this implementation prohibits 
using dynamic panes). It is straightforward to derive a class from MFC’s CTreeView to 
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provide the necessary support for the tree control. However, there is more information to be 
displayed in the right pane than there is room. 

Windows™ provides tab controls to manage multiple dialogs. The combination of a 
tab control and its dialogs is often referred to as a property sheet. MFC encapsulates this 
behavior with CPropertySheet and CPropertyPage. Property sheets provide a convenient, 
efficient way to partition and display large amormts of information. 



Figure 6: Installed Protocols GUI Layout 


Figure 6 shows the layout for the installed protocols GUI. The protocols are grouped 
in the tree control according to their service provider. The property sheet displays the 
information corresponding to the selected node in the tree control. This information is 
grouped into three sections: basic information, service flags, and socket specific parameters. 
The basic information property page will include the protocol name, globally unique 
identifier (GUID), catalog entry number^, and provider flags. The next property page lists 
the 19 service support flags, including guaranteed delivery, broadcast, and QoS. The third 
property page contains the parameters needed to instantiate a socket for this protocol. 


^ This number indicates the service provider’s relative priority and is used to determine default behavior. Priorities are 
set based on installation order and can be changed with the sporder.exe utility included with Winsock 2. 
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The installed adapters GUI layout in Figure 7 is almost identical to the installed 
protocols GUI layout. However, the dialog associated with the Details tab in this GUI will 
depend on the selection in the tree control. If a hardware component is selected, a dialog for 
that type of hardware will list its settings. For example, if an Ethernet NIC is selected, its 
Ethernet address, media type, and other settings will be displayed along with universal 
parameters of interrupt, slot number, etc. An ATM NIC, on the other will include 
buffer sizes, cell rates, and other ATM settings. 

Bindings control how network adapters and protocols interface with each other. 
Windows™ NT supports viewing and editing bindings under Settings Control 
Panel->Network^Bindings. Because a convenient interface with the bindings is provided, 
there is no compelling reason to display the bindings in the networking analysis package. 

D. NETWORK ACCESS AND TIMING 

In order to function, network analysis software must establish realistic 
communications and accurately measure the performance of those connections. Because 
timing support is included in this network access implementation, timing events in Windows 
NT will be examined first. Then, adding timing and measurement capabilities to the 
windows sockets in support of networking application development and performance 
benchmarking will be explored. 
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1. Timing and Timers 

Because we are interested in measuring performance, accurately timing networking 
events is critical. The NT kernel offers three primary ways to time events: timers, high- 
performance timers, and perforaiance counters. Standard timers have a resolution on the 
order of milhseconds, making them unfit for performance benc hmar king. High-perfonnance 
timers are implemented with performance counters. 

Performance counters are 64-bit values stored in the registry that are monotonically 
incremented, typically by device drivers. These counters can be used to measure many rates 
of performance. The performance monitor in Windows™ NT allows installed performance 
counters to be selected and displayed, including processor, networking, and system tasks. 
While the performance monitor can measure many network events^, it reports the aggregate 
activity of installed components not the performance of the attached network or specific 
communications channels. 

The Windows™ API returns performance counter values as LARGEJNTEGER 
unions. This union allows the values to be manipulated as either 64-bit integers or as two 
32-bit integers. The Visual C-h- compiler includes native support for 64-bit integers usin g 
the ZOWGZOVG type. 

Windows™ NT provides precision timing through the QueryPerformanceCounterQ 
and QueryPetformanceFrequencyO API fimctions. The performance frequency on Intel™ 
based computers typically provides timing resolution on the same order as the processor 
clock speed. 

The precision of high-resolution timing results gives a false sense of accuracy. Each 
performance cormter measurement may include observation noise. Windows™ NT is a 
preemptive multitasking system and may pause the current thread execution without 
warning. In addition, access to the registry, memory, and other system resources are queued 
for servicing, introducing random processing delays. 


* The Network Monitor service must be loaded to obtain TCP/IP statistics. 
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2. Socket Support 


Sockets provide the communications support necessary for networking support, but 
do not include the tuning for analysis. Socket conununications can be developed using the 
native Winsock API calls or a MFC socket class. CAsyncSocket encapsulates the Winsock 
functionality. It requires the programmer to account for network byte order differences, 
multi-byte character sets (MBCSs), and other low-level issues. CSocket is derived from 
CAsyncSocket and accounts for these issues, at the cost of additional overhead. 

Because efficiency and execution time is critical when trying to accurately measure 
events, this project’s performance-aware socket class is derived from CAsyncSocket and 
overrides its methods so they conform to the following pseudo code procedure: 

• Variable initialization and translation 

• Start = performance timer 

• CAsyncSocket: rXhisFunctionO; 

• Stop = performance timer 

• Return (Stop - Start) 

For example, substituting WSAConnectQ or r.ConnectQ for CAsyncSocket:-.ThisFunctionQ 
gives an implementation to measure call setup time. By only measuring the duration of the 
actual communications function, the effect of the conditions in the local machine are 
minimized. This provides the most likely estimate of the actual service rate provided by the 
underlying networks and is an upper limit to network performance a user can expected on 
that machine. 

Microsoft™ products are notorious for containing bugs. I found that the Winsock 
2.0 receiveO family of functions fail to properly timeout when called from a user thread. 
This is probably because the active window improperly hooks the WMJTIMER message 
generated by the timeout. In any case, this situation can be avoided by using selcctQ to wait 
for incoming data. Once selectQ verifies valid data is queued, the receiveQ functions can 
safely retrieve it. 

E. COMMUNICATIONS CONTINUITY AND CONNECTIVITY 

Networking performance cannot be measured without reliable communications. 
Two command-line utilities, ping and tracert, exploit internet control message protocol 
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(ICMP) to verify connectivity and determine the routing path. This networking analysis 
package will include enhanced versions of these utilities. While this thesis only implements 
these utiUties using with ICMP, it could be expanded to provide the same flmctionahty for 
other type of networks using the same interface (determining the routing path of a VPWCI 
pair would be a useful improvement). 

1. ICMP and IP 

ICMP is typically considered part of the IP layer and is explained in detail by 
Stevens in [3]. At its most basic level, ICMP is used to send control and error messages 
across an P based network. An ICMP echo request causes the target network node to 
retransmit the packet’s contents back to the transmitting station. This is a simple and 
convenient method to verify connectivity. 

By also using the time-to-live (TTL) field in the P header, the maximum number of 
hops can be set. Each time an P packet is routed, its TTL is decremented. When the TTL 
reaches zero, the packet is discarded and an ICMP time exceeded message is sent back to the 
transmitter. By successively sending P packets with increasing TTL values, the transmitting 
station will receive ICMP messages firom each routing point in the path to the target station. 

2. Implementation Issues 

At the P layer, implementing ping and tracert is straightforward, almost trivial. 
Unfortunately, Winsock does not provide direct access to the P layer. Sockets of type 
RAW/P do allow most of the P header files to be set via Winsock API functions. However, 
only processes with administrator privileges are allowed to instantiate RAW sockets. 
Therefore, this network analysis software will provide connectivity and continuity support 
only to users with administrator access on the host machine. 

3. GUI 

One way to improve over the available ping and tracert utilities is to fully leverage 
the advantages of the Windows'™ NT graphical environment. The general layout for the 
connectivity and continuity test dialog is shown in Figure 8. Each of its sections is discussed 
below. 
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Figure 8: Connectivity and Continuity GUI Layout 

One significant advantage over the command-line ping utility is the ability to select 
the network adapter with which to test the network. The user typically has no control of 
which NIC is used in a multi-NIC computer. The drop-down list box control allows the user 
to choose from all installed adapters^, even though not all adapters support ICMP (e.g. 
native ATM adapter). This list could be filtered to show only adapters that support ICMP; 
however, limiting information in this context seems counterintuitive. 

A drop-down combination box control is used to allow the user to either type in the 
target address or select one from history. The 20 previous targets are stored in the registry jn 
registry and are loaded during program initialization. Because target addresses are typically 
used more than once, this feature is both convenient and timesaving. 

The text control formats and displays results according to the user-selected options. 
It includes a slider so previous results can be viewed after they have scrolled off the screen. 
This control uses a 64k buffer for text, limiting it to about 800 lines—more than sufficient. 
The user also has the option of clearing the control of text. The control is set as read only. 


^ The adapter list provided by NT is really a list of the installed drivers. Typically, Ethernet NICs have only one 
driver. However, ATM NICs will have at least two, one for ATM and another for IP over ATM. 
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preventing user alteration; its window inactive attribute is set, preventing selection and 
protecting cursor placement. 

The output is customizable, allowing the user to select which event(s) to time and 
display from the following list: 

• Socket Creation 

• Name Resolution 

• Reply (Always reported) 

• Timeout 

Measuring the duration of operations that timeout helps to verify the operation of the local 
timeout mechanism. The user can also select whether the times are displayed in milliseconds 
or microseconds and the number of significant digits to report. 

Because of the close relationship between verifying continuity and determining 
connectivity, both functions are implemented in this single interface. The user selects the 
active operation mode with the radio button control. 

F. BENCHMARKING 

The primary measure of network performance is data throughput. This analysis suite 
provides performance benchmarks by establishing a co mmuni cations session with a remote 
host, transmitting data, and measuring the transmission times. The results must be displayed 
in an intuitive format, accurately reflecting network performance. The user interface should 
also be generic enough to apply to different types of networks. The general format of the 
GUI is shown in Figure 9. 
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Figure 9: Benchmarking GUI Layout 

Each of the ciirrent benchmarks being conducted will be listed in a text control at the 
bottom of the dialog. This control will list the connection id (VPWCI for ATM, TCP port 
number for TCP/IP, etc.), the latest measured throughput, and the average throughput over 
the life of the connection. In addition, the text color will match the color of the trace in the 
performance plot. 

The graph will plot the performance measurements of each running connection. The 
time axis runs fium left to right and uses a user-defined resolution. The vertical axis will 
represent the units selected by the user and may represent different measures for different 
session. For example, an ATM connection may be displayed in cells per second alongside a 
TCP/IP connection displayed in bytes per second. When the results exceed the maximum 
index on the time axis, the plot is scrolled to the left by one time resolution. This results in 
new measurements being added at the far right of the plot so the full time range of values 
can be seen. Old measurements are discarded as they scroll off the left edge of the graph. 

A separate dialog is used to establish benchmark connections. This allows the 
software to use custom dialogs to obtain the information needed for each type of connection. 
This permits using the same GUI to display results for different types of connections. This 
consistent interface simplifies use and facilities future expansion. 
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This GUI is very robust; however, not all its capabilities are used. The GUI can 
support multiple concurrent benchmarks, but the underlying measurement implementation 
cannot. To measure the performance of multiple connections accurately, each connection 
must run in its own thread of execution. The groundwork for multi-threaded support is laid, 
but it is not fully functioning at this time. Also, only TCP/IP and ATM AAL5 connections 
are supported. 
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rV. RESULTS AND PERFORMANCE 


While developing this network analysis software, the underlying fundamental design 
criteria have remained relatively unchanged. However, the GUI layouts have continually 
evolved as experience has revealed improved approaches. The following is a description of 
the first version of this software package: NetMan 1.0. In addition to providing a guide to 
operation, this will provide a baseline to measure future editions against. 
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Figure 10; Service Providers/Protocols GUI 1 

The first incarnation of the installed protocols GUI is shown in Figure 10. This GUI 
works on monitors running at resolutions of 1^00x1600. Because this GUI only worked 
well on 21” monitors at this high resolution, the GUI in Figure 11 was developed. 
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Figure 11: Service Providers/Protocols GUI 2 



























The connectivity and continuity testing GUI and its options GUIs are shown in 
Figure 12. In this example, the ping operation used the local Ethernet NIC; the trace 
operation used the ATM NIC. With all events selected in the Reporting dialog, socket 
creation/binding to local address and name resolution times are measured and displayed. 
Because this version only implements connectivity and continuity tests using ICMP, the 
selected ATM adapter must support TCP/IP. 
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Figure 12: Continuity and Connectivity GUI 







The benchmarking GUI is shown in Figure 13. Call set-up times are measured for 
connection-oriented protocols by timing the operation of the WSAConnectQ function. This 
returns the tune required for the local socket to establish a connection to a remote socket. 
Throughput refers to the amount of actual data supplied to the transport layer for transfer. 
Data rate measurements include the overhead added by the transport and network layers. 

These measurements include only the performance of the associated connection^ 
therefore, they provide the best estimate for the networking performance an application will 
receive. The performance monitor statistics available in Windows™ NT are a measure of 
network activity and include all network traffic. 
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Figure 13: Performance Benchmarking GUI 








In order to generalize the performance benchmarking GUI to support different 
protocols and types of service, the GUI shown in Figure 14 is used to separate the call-setup 
procedure from the main GUI. This will help in migrating the software to multithreaded 
operation. In addition, when the software is expanded to support different QoS coimections, 
an additional dialog can be added to allow the parameters specific to that type of coimection 
to be set. 
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Figure 14: Benchmarking Call-Setup GUI 
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V. CONCLUSION 


A. SUMMARY OF WORK 

This thesis has thoroughly investigated how Windows™ NT implements networking 
support and demonstrated that implementation details are significant to observed network 
performance. The network analysis software developed is functional and provides a valuable 
resource for both network administrators and networking researchers. The software provides 
complete descriptions of a host’s networking configuration, significantly improved versions 
of ping and tracert, and measures both call-setup time and throughput performance of 
TCP/IP and ATM AAL5 best effort connections. 

B. FUTURE WORK 

This network analysis software is stmctured to facilitate upgrades and expansion. In 
addition to improving and adding valuable utility, further work will provide more ins ight 
into advanced networking implementation and analysis issues. Some specific improvements 
include: 

1. Implementing multi-threaded support. This will allow networking performance 
to be measured as fimctions of operating system load and application priority 
level in addition to raw network throughput. 

2. Expanding ATM support to include other AALs. 

3. Allowing the user to set QoS parameters for each connection. 

4. Providing the ability to remotely view the networking configuration or measure 
performance benchmarks from any Windows™ NT machine in that domain. 

5. Supporting Telnet, FTP, and rlogin functions. 
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APPENDIX A. INFORMATION TECHNOLOGY FOR THE TWENTY-FIRST 

CENTURY (IT-21) 
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R 300944Z MAR 97 ZYB PSN 077820Q24 
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TOALPACFLT 

ALLANTFLT 

INFO RUENAAA/ASSTSECNAV RDA WASHINGTON DC//C4I// 

RUENAAA/CNO WASHINGTON IX://N()0/N09/N095/N2/N4/N41/N43/N46/N6/N6B/ 

N8/N80/N85/N86/N87/N88// 

RUCBCLF/CINCLANTFLT NORFOLK VA//N00/N6// 

RUCBACM/CINCUSACOM NORFOLK VA//J00/J6// 

RHHMUNAAJSCINCPAC HONOLULU HI//J00/J6// 

RHDLCNE/CINCUSNAVEUR LONDON UK//00/N6// 

RULSSEA/COMNAVSEASYSCOM WASHINGTON DC//N00/N08/PMS335/PMS3 
RUENMED/BUMED WASHINGTON DC//N00// 

RHRMDAB/RUCJNAV/COMUSNAVCENT//NOO/N6// 

RUCTPOA/CNET PENSACOLA FIV/NOO// 

RUEACNP/BUPERS WASHINGTON DC//N00// 

RUHEHMS/COMMARFORPAa/CG/G6// 

RUCKMAA/COMMARFORLANT//CG/G6// 

RULSSPA/COMSPAWARSYSCOM WASHINGTON DC//N00/N05/PMW171/PMW176// 

RUWFADO/NAVSTKAIRWARCEN FALLON NV//N00// 

RULKSDF/COMNAVSECGRU FT GEORGE G MEADE MD//N00// 

RULSAMX/COMNAVSUPSYSCOM MECHANICSBURG PA//N00// 

RUWFAFK/COMNAVSPECWARCOM CORONADO CA//NOO// 

RULSADG/NRL WASHINGTON DC//N00// 

RULSWCB/COMNAVCOMTELCOM WASHINGTON DC//N00/N3// 

RUCOSAO/NAVMASSO CHESAPEAKE VA//N00/N6// 

RUWFOAA/NCCOSC RDTE DIV SAN DIEGO CA//N433// 

RHHMHAH/CINCPACFLT PEARL HARBOR HI//N00// 

BT 

UNCLAS //N05230// 

ALPACFLT 008/97 

MSGID/GENADMIN/CINCPACFLT/008// 

SUBJ/INFORMATION TECHNOLOGY FOR THE 2F CENTURY// 

POC/M.K SCOTT/CDRN6/CINCPACFLTA/TEL: 808 471-8637// 

POC/D.A. STRAUB/CDRN6/CINCLANTFLTAyTEL: 757 322-5863// 

RMKS/1. THIS IS THE FIRST IN A SERIES OF JOINT CINCPACFLT AND CINCLANTFLT MESSAGES CONCERNING THE 
DEVELOPMENT AND IMPLEMENTATION OF IT-21. THIS MESSAGE PROVIDES IT-21 HARDWARE/SOFTWARE 
IMPLEMENTATION STANDARDS FOR PROGRAMS INSTALLING INFCKMATION SYSTEMS ON FLEET UNITS/BASES AND 
PROVIDES THE FLEET WITH GUIDANCE ON MAINTAINING EXISTING INFORMATION SYSTEMS UNTIL INSTALLATION 
OF IT-21 PRODUCTS. THE IT-21 IMPLEMENTATION STANDARDS OUTLINED BELOW ARE PROMULGATED IN ADVANCE 
OF DON-WIDE GUIDANCE FROM THE DON CHIEF INFORMATION OFHCER (CIO). THE DON CIO WILL PROMULGATE 
DON-WIDE STANDARDS FOLLOWING NEGOTIATION OF ENTERPRISErWIDE NETWORK OPERATING SYSTEMS AND 
APPLICATIONS. 

2. BACKGROUND: INFORMATION SUPERIORITY IS'THE FOUNDATION OF JOINT VISION 2010 BATTLEFIELD 
DOMINANCE, AS WELL AS THE WARFIGHTING VISION FOR EACH SERVICE. NETWORK WARFARE, ROBUST 
INFRASTRUCTURE AND INFORMATION DISSEMINATION TO DISPERSED FORCES ARE KEY ELEMENTS IN ACHIEVING 
INFORMATION SUPERIORITY. IT-21 IS A FLEET DRIVEN REPRIORTEZATION OF C4I PROGRAMS OF RECORD TO 
ACCELERATE THE TRANSITION TO A PC BASED TACTICAL/TACTICAL SUPPORT WARFIGHTING NETWORK. THE 
INACTIVATION OF THE CURRENT DOD MESSAGING SYSTEM (AUTODIN) BY DEC 99, WITH NO PLANNED NAVY 
INFRASTRUCTURE REPLACEMENT, MANDATES THE RAPID IMPLEMENTATION OF THIS WARFIGHTING NETWORK. 

3. COMMERCIAL NETWORK OPERATING SYSTEMS (NOS) AND E-MAIL PRODUCTS HAVE ACHIEVED FUNCTIONAL 
PARITY. THE FLEETS CANNOT CONTINUE TO SUPPORT A MULTITUDE OF DIVERSE OPERATING SYSTEMS AND E- 
MAIL PRODUCTS WITH THEIR OWN TRAINING, OPERATIONAL PROCEDURES AND TROUBLESHOOTING 
REQUIREMENTS. THE DOD JOINT TECHNICAL ARCHITECTURE (JTA) AND DEFENSE INFORMATION INFRASTRUCTURE 
COMMON OPERATING ENVIRONMENT (DII COE) PROVIDE DOD WITH THE AIS SYSTEM GUIDANCE REQUIRED TO 
TAKE THE NAVY INTO THE 21®^ CENTURY. THIS CONVERGENCE OF SOLUTIONS, PROBLEMS AND GUIDANCE 
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PROVIDES THE IMPETUS TO ESTABLISH MINIMUM NAVY AIS STANDARDS AT THIS TIME. IMPLEMENTATION OF THIS 
POLICY REQUIRES ALL NON-STANDARD NOS AND E-MAIL PRODUCTS BE REPLACED NLT DEC 99. 

A. WINDOWS NT SERVER 4.0 IS THE STANDARD FLEET NOS. IT WILL SOON BE FOLLOWED BY WINDOWS NT 5 0 

WINDOWS NT SERVER 4.0 IS DII COE COMPLIANT. wj. in d.u. 

B. MS EXCHANGE IS DESIGNATED AS THE STANDARD E-MAIL SOLUTION FOR BOTH FLEETS TO ENSURE AN 
INTEROPERABLE SECURE MESSAGING SYSTEM IS OPERATIONAL PRIOR TO AUTODIN INACTIVATION NLT DEC 99 

C. MS OFFICE 97 IS DESIGNATED AS THE STANDARD FLEET OFFICE SOFTWARE. 

D. EXPENDITURE OF OPERATING FUNDS TO MAINTAIN EXISTING IT-21 NONCOMPLIANT NOS AND APPLICATIONS 
SHALL BE THE ABSOLUTE MINIMUM NECESSARY TO MEET OPERATING REQUIREMENTS UNTIL IT-21 NOS/SOFTWARE 
IS INSTALLED EVEN IF TEMPORARY LN DEGRADATION OCCURS. SOFTWARE REQUIREMENTS DRIVE HARDWARE 
STANDARDS. HARDWARE AND SOFTWARE PURCHASED TODAY MUST BE CAPABLE OF MEETING MISSION 
REQUIREMENTS THROUGH THE YEAR 2000. 

4. CINCPACFLT AND CINCLANTFLT ARE ACTIVELY WORKING WITH OPNAV ON IT-21 FUNDING AND 

IMPLEMENTATION PLANS. IN GENERAL, AFLOAT IT-21 IMPLEMENTATION WILL BE LINKED TO DEPLOYING 
BATTLEGROUPS AND ASHORE IT-21 WILL BE IMPLEMENTED IN A PHASED APPROACH. SPECIFIC IMPLEMENTATION 
SCHEDULES WILL BE PROMULGATED AT A LATER DATE. CINCPACFLT AND CINCLANTFLT ARE TRANSITIONING TO 
WINEXDWS NT 4.0, MS EXCHANGE AND MICROSOFT OFFICE 97. THIS ENVIRONMENT CANNOT BE OPTIMIZED 
WITHOUT 32 BIT OPERATING SYSTEMS, HIGH RESOLUTION DISPLAYS AND MASS STORAGE. ATM BACKBONE LANS 
WITH AT LEAST 100 MBS (TCP/IP)TO THE DESKTOP PC WILL BE INSTALLED ON ALL SHIPBOARD LANS FLEET 
HEADQUARTERS (CPF, CLF, TYCOMS, GROUP AND SQUADRON COMMANDS) AND SHOULD BE INSTALLED IN THOSE 
SHORE ACTIVITIES THAT SUPPORT TACTICAL OPERATIONS. THIS WILL THEN ALLOW TRANSITION TO ATM-TO- THE- 
DESKTOP PC WHEN THE ATM TECHNOLOGY MATURES. ^ iivi -1 w inn 

5. SYSTEM COMMANDS AND PROGRAM MANAGERS: 

A. NTCSS WILL BECOME THE IT-21 PROGRAM OF RECORD FOR INSTALLATION OF BOTH SECRET AND 
UNCLASSIFIED LANS ONBOARD COMMISSIONED SHIPS. NTCSS (ATIS/SNAP III) LANS INSTALLED FROM THIS POINT 
ON WILL HAVE AN ATM BACKBONE, 100 MBS (FAST ETHERNET) TO THE DESKTOP PC AND THE 
HARDWARE/SOFTWARE OUTLINED AT THE END OF THIS MESSAGE. THE MIGRATION OF NTCSS LANS TO HIGHER 
CAPACITY LANS WILL REDUCE THE NUMBER OF PC’S DELIVERED DURING INITIAL INSTALLATION. THE TRADEOFF 
OF QUANTITY FOR FRONT END PC’S IS REQUIRED TO SUPPORT JV-2010 AND AUTODIN INACTIVATION. 

B. SPA WAR IS WORKING WITH NAVSEA TO ENSURE THAT LANS INSTALLED DURING NEW CONSTRUCTION MEET 
THE IT-21 REQUIREMENTS. 

C. APPLICATION PROGRAM MANAGERS SUCH AS JMCIS, NSIPS, TAMPS, AND GCSS SHOULD MIGRATE CURRENT 

APPLICATIONS TO THE DII COE WITH AN IMMEDIATE OBJECTIVE OF OBTAINING PC WORKSTATION ACCESS TO ALL 
APPLICATION DATA ON AN ENTERPRISE LAN. u all 

D. PROGRAMS INSTALLING INFORMATION SYSTEMS (NEWNET, SMARTLINK, SMARTBASE, TELEMEDICINE ETC ) 
MUST INSTALL COMPONENTS IN FLEET ACTIVITIES THAT MEET IT-21 STANDARDS AND PROVIDE 
INTEROPERABILITY THROUGHOUT THE WARFIGHTING NETWORK. 

6. TYCOMS AND THIRD ECHELON COMMANDS SHALL ENSURE THAT: 

A. SHIPS AND ACTIVITIES INSTALLING NEW LANS, UNDERGOING SIGNIFICANT LAN UPGRADES OR THOSE 

ACTIVITIES WITH STAND ALONE PC’S SHALL INSTALL IT-21 HARDWARE AND SOFTWARE. NEW OR REPLACEMENT 
SHIPBOARD AND SHORE BASED TACTICAL LANS SHOULD HAVE AN ATM BACKBONE WITH AT LEAST 100 MBS (PAST 
ETHERNET) TO THE PC. ^ v ^ 

B. SHIPS AND ACTIVITIES WITH EXISTING LANS, WHICH REQUIRE REPLACEMENT OF UNSERVICEABLE 

HARDWARE, SHORT OF A FULL NETWORK UPGRADE, SHALL INSTALL HARDWARE WHICH MEETS IT-21 STANDARDS 
THE NEW EQUIPMENT MAY NOT BE COMPATIBLE WITH THE EXISTING LAN HARDWARE. CINCPACFLT AND 
CINCLANTFLT BELIEVE THAT ALL AUTOMATED INFORMATION SYSTEMS (AIS) PROCURED MUST BE COMPATIBLE 
WITH THE IT-21 LAN STANDARDS EVEN IF TEMPORARY LAN DEGRADATION OCCURS. THERE IS ONLY SUFFICIENT 
FUNDING TO DO IT RIGHT THE FIRST TIME. riciniN i 

7. THE IT-21 STANDARDS BELOW REPRESENT FRONT END MARKET TECHNOLOGY, ARE DYNAMIC IN NATURE AND 

CONTINUE TO BE CLOSELY LINKED TO COMMERCIAL TRENDS. THE STANDARDS LISTED BELOW ARE 
INTENDED TO BE MINIMUM STANDARDS AND WILL BE UPDATED PERIODICALLY 
A. IT-21 LAN: 

(1) AFLOAT LAN STANDARDS - ATM FIBER BACKBONE, 100 MBPS (FAST ETHERNET) TO THE PC. 

(2) ASHORE TACTICAL AND HEADQUARTERS COMMAND CENTER STANDARD (CPF, CLF, TYCOMS GROUP AND 
SQUADRON COMMANDS) - ATM BACKBONE, 100 MBPS (FAST ETHERNET) TO THE PC. 

(3) ASHORE TACTICAL SUPPORT COMMAND STANDARDS (BASES)- ATM BACKBONE, 100 MBPS (FAST ETHERNET) 
TO THE PC. 

B ^IT*2f area NETWORKS (MAN) SHOULD BE CAPABLE OF SUPPORTING AT LEAST OC-3 (155MBS). 

- WINDOWS NT 4.0/5.0 WORKSTATION 

- MS OFFICE 97 PROFESSIONAL (WORD 97, POWERPOINT 97, EXCEL 97 S 
ACCESS 97) 

- IBM ANTI VIRUS (NAVY LICENSE, AVAIL FROM NAVCIRT) 

- MS BACK OFFICE CLIENT 
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-MS OUTLOOK 97 
-MS EXCHANGE 5.0 

- MS IMAGE COMPOSER 

C. IT-21 DATABASES. RELATIONAL DATABASES THAT CAN SUPPORT WEB TECHNOLOGY lAW THE COE (ORACLE 
SYBASE, SQL SERVER, ACCESS, ETC.) WILL BE USED TO SUPPORT DATA REQUIREMENTS AND APPLICATION 
DEVELOPMENT. ALL PROCESS ENGINEERING INITIATIVES THAT RESULT IN DESIGN/REDESIGN OF A DATA 
COLLECTION/CAPTURE SYSTEM MUST USE COE COMPLIANT RELATIONAL DATABASE MANAGEMENT SYSTEMS 
(RDBMS) SOFTWARE. THIS REQUIREMENT IS PROVIDED TO ENSURE RDBMS INITIATIVES USE COTS APPLICATION 
SOFTWARE. FOR ADDITIONAL INFORMATION ON RELATIONAL DATABASES CONTACT CDR SANDY BUCKLES, CPF 
N67, COMM/DSN (808) 474-6384, NIPRNETniailto:U67@CPF-EMH.CPF.NAVY.MIL. 

D. MINIMUM IT-21 PC CAPABILITIES: CPF CAN CURRENTLY PURCHASE THE IT-21 STANDARD PC WITH SOFTWARE 
FOR $3250.00- S3579.00- SEE PARA 7(H) AND 7(1). 

- 200 MHZ PENTIUM PRO CPU 
-64MBEDORAM 

-3.0 GB HARD DRIVE 

- 3-5 INCH FLOPPY DISK DRIVE 
-8X IDE CD-ROM 

- DUAL PCMCIA/PC CARD READER 

- PCI VIDEO W/2MB RAM 

- 17 INCH MONITOR (1280 X 1024) 

- POINTING DEVICE (TRACKBALL OR MOUSE) 

- SOUNDBLASTER (COMPATIBLE) AUDIO CARD WITH SPEAKERS KEYBOARD 

- CPU COMPATIBLE 100 MBPS FAST ETHERNET NIC 

E. STANDARD IT-21 LAPTOP WORKSTATION: APPROXIMATELY $5300- 
SEE PARA 7(H). 

-150 MHZ PENTIUM 
-32 MB EDO RAM 

- 12.1 IN SVGA ACTIVE MATRIX COLOR DISPLAY 
-2.1GB HIDE HDD 

- 6X INTERNAL CD-ROM 

- MODEM, PCMCIA SLOTS, NIC CARD 

- SMART LITHIUM BATTERY 

F. IT-21 NT FILE SERVER FOR DIRECTORY NETWORK SERVICE: APPROXIMATELY $26K- SEE PARA 7(H). THESE ARE 
MINIMUM SPECIFICATIONS. NEEDS OF THE SPECIFIC NETWORK WILL DICTATE REQUIREMENTS. 

- DUAL 166 MHZ PENTIUM CPU 

- 512K SECONDARY CACHE MEMORY- 256 MB RAM 
-TWO4 GB SCSI HDD 

-ONE 6 GB DAT DRIVE 

- ONE 3.5 INCH FLOPPY DISK DRIVE 
-6X SCSI CD-ROM 

- DUAL PCMCIA/PC CARD READER 

- 2 DPT SCSI m CACHING CONTROLLERS (SMARTCACHE 4) 

- PCI VIDEO W/2MB RAM 

- 17 INCH MONITOR (1280 X 1024) 

- POINTING DEVICE (TRACKBALL OR MOUSE) 

-KEYBOARD 

- TWO CABLETRON CPU COMPATIBLE ATM NIC CARDS 

ANTEC DUAL POWER SUPPLY CASE (HOT SWAPPABLE) 

G. IT-21 FILE SERVER/APPLICATION SERVER: APPROXIMATELY $26K- SEE PARA 7(H). SAME AS IT-21 NT FILE 
SERVER FOR DIRECTORY NETWORK SERVICE WITH THE FOLLOWING CHANGES: 

- CHANGE HDD RQRMT TO FIVE 4 GB DRIVES 
-CHANGE DAT TO 18 GB. 

H. PRICES FOR PC TECHNOLOGY ARE CONSTANTLY CHANGING AND CAN VARY GREATLY DEPENDING ON 
METHOD OF PROCUREMENT, FOR EXAMPLE, ON 28 MAR 97 AN IT-21 PC PURCHASED DIRECTLY FROM A VENDOR 
COSTS $3643. GOVERNMENT RATE FOR SMALL PURCHASES (LESS THAN TEN) IS $3579. A BULK PROCUREMENT (MORE 
THAN SEVENTY-FIVE) COSTS $3250. THE ABOVE PRICES INCLUDE SHIPPING. BULK PROCUREMENTS SHOULD BE 
MADE THROUGH THE TYPE COMMANDERS WHEN APPROPRIATE, MR RICK KOOKER CPF N65, COMM/DSh©808) 474- 
5882, NIPRNET: U65@CPF-EMH.CPF.NAVY.MIL IS AVAILABLE TO ASSIST TYCOMS WITH AIS PROCUREMENT ISSUES. 

I. AS NETWORK COMPUTER TECHNOLOGY EVOLVES SOME COMMANDS MAY BE ABLE TO TRANSITION TO 
NETWORK COMPUTERS. WHEN CONSIDERING INSTALLATION OF NETWORK COMPUTERS, TOTAL NETWORK COST 
MUST BE EVALUATED. NETWORK COMPUTERS HAVE NOT MATURED SUFFICIENTLY TO IMPLEMENT THEM IN FLEET 
PLATFORMS AT THIS TIME. 

8. WAIVER REQUESTS FROM THE ABOVE STANDARDS SHOULD BE SUBMITTED DIRECTLY TO THE RESPECTIVE 
CPF/CLFN6. POINTS OF CONTACT ARE AS FOLLOWS: 

A. CINCLANTFLT: CDR DEBRA STRAUB AT COMM (757) 3225863, NIPRNET: mailto:U6@CLF.NAVY.MIL 

B. CINCPACFLT: CDR MIKE SCOTT AT COMM (808) 4747860, NIPRNET:U6@CPBEMH.CPF.NAVY.MIL,// 
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APPENDIX B. HUNGARIAN NOTATION 


Hungarian notation uses prefixes to identity a variable’s type and is widely used in 
Windows coding. There are many, often incompatible, dialects. Following are the 
conventions I found to be most common and used in developing my code. 


Prefix Corresponding type 


a 

b 

c 

C 

ch 

ctl 

d 

dw 

f 

g_ 

h 

i 

i64 

1 

Ip 

1st 

m_ 

nis_ 

mnu 

n 

0 

P 

s_ 

str 

sz 

txt 

u 

v 

w 

WM_ 

wnd 


array 

Boolean 

count 

class 

char (NOT equal to a b 5 de if UNICODE or MBCS is defined) 

Windows control 

double 

DWORD 

float (Another common usage is for flag i.e. a Boolean variable) 

global 

handle 

int 

LARGE_INTEGER 

long 

far* 

list box 

member variable 
member static 
menu 

int (Microsoft™ code will use this for uint variables too) 

object 

pointer 

static 

CString 

NULL terminated string 

text control 

unsigned 

void 

word 

Windows message 
window 
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APPENDIX C. CLASS OVERVIEW 


CAboutDialog 

Derived from CDialog, this class implements the Help->About menu selection. 


CAdapterFormView 

Derived from CFormView, this class displays network adapter parameters in a 
dialog resource. 


CAdapterSplitWnd 

Derived from CMDIChildWnd, this class manages the window used to display the 
network adapter parameters. It includes a CSplitterWnd, CAdapterTreeView, and 
CAdapterFormView objects. 


CAdapterTreeView 

Derived from CTreeView, this class manages the tree control and organizes installed 
adapter drivers by NIC. 


CGraphCtl 

Derived from CStatic, this class plots line graphs in the area defined by a static 
dialog control. It relies on CObservedPerformanceArray for scaling. 

CIcmpPacket 

This class encapsulates the tasks for working with ICMP messages. 


CMainFrame 

Derived from CMDIFrameWnd, this class manages the menu bar and all child 
windows. 


CNetBenchFormView 

Derived from CFormView, this class implements the performance benc hmarkin g 
GUI. It requires CPerformanceSocket, CWeightedInterval, and CGraphCtl. 
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CNetManApp 

Derived from CApplication, this class manages the application primary thread. 


CNetManDoc 

Derived from CDocument, this class retrieves configuration data from the registry 
and provides that data to any CView derived class that requests it. 


CObservedPerformanceArray 

This class stores an array of CWeightedInterval objects and translates the results to a 
given resolution. This class provides data that can be directly used by CGraphCtl. 


CPerformanceSocket 

Derived from CAsyncSocket, this class provides full socket functionality and returns 
a CWeightedInterval describing the execution time. 


CPingFormView 

Derived from CFormView, this class implements the continuity and connectivity 
(ping and traceri) GUI. It uses CPe^ormanceSocket, CTraceOptionsDialog, 
CPingOptionsDialog, and CreportingOptionsDialog. 


CPingOptionsDialog 

Derived from CDialog, this class encapsulates the dialog used to set the user- 
selectable options for the ping mode of operation. 


CProtocolFormView 

Derived from CFormView, this class displays the the information about a selected 
protocol. It is has been replaced by CProtocolPropertySheetView. 


CProtocolPropertyPageGeneral 

Derived from CPropertyPage, this class handles the dialog associated with the 
General tab of the protocol property sheet. 
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CProtocolPropertyPageServiceFlags 

Derived from CPropertyPage, this class handles the dialog associated with the 
Service Flags tab of the protocol property sheet. 


CProtocolPropertyPageSocketParameters 

Derived from CPropertyPage, this class handles the dialog associated with the 
Socket Parameters tab of the protocol property sheet. 


CProtocolPropertyPageUtil 

Derived from CPropertyPage, this class handles the dialog associated with the 
Utilities tab of the protocol property sheet. The access to these utilities will be moved to the 
main menu bar in future versions. 


CProtocolPropertySheet 

Derived from CPropertySheet, this class handles the protocol property sheet control. 
It contains instances of the following classes: CProtocolPropertyPageGeneral, 
CProtocolPropertyPageServiceFlags, and CProtocolPropertyPageSocketParameters. 


CProtocolProertySheetView 

Derived from CView, this class provides CView functionality to 
CProtocolPropertySheet. Multiple inheritance is not used because of MFC limitations. 


CProtocolSplitWnd 

Derived from CMDIChild, this class contains the CSplitter object. It also includes a 
global variable to facilitate communication between CProtocolTreeView and 
CProtocolPropertySheet. 


CProtocolTreeView 

Derived from CTree View, this class manages the tree control and organizes installed 
protocols by service provider. 


CReportingOptionsDialog 

Derived from CDialog, this class encapsulates the dialog used to set the user- 
selectable timing options. 
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CTraceOptionsDialog 

Derived from CDialog, this class encapsulates the dialog used to set the user- 
selectable options for the trace mode of operation. 

CWeightedInterval 

This class contains a start time, stop time, and a weight value. This application uses 
the weight to represent a number of bytes. This class will return data in a number of 
different formats, including CPomr(niidpoint, weight); CPomr(endpoint, weight); and 
CPomr(endpoint, weight/range). 
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